Please address the comments from this code review:

## Overall Comments
- In `_reduce_sum_numpy`, the return type annotation (`np.uint64 | np.float64 | np.ndarray`) no longer quite matches the behavior now that integer/bool paths can return `np.int64` scalars; consider tightening the hint (e.g., to `np.generic | np.ndarray`) or explicitly including `np.int64`.
- The accumulator selection in `_reduce_sum_numpy` treats all non-`uint8` integer and bool dtypes as `int64`; if you expect larger unsigned types (e.g., `uint32`/`uint64`), consider branching on signedness and itemsize to avoid surprising overflow or sign changes.

## Individual Comments

### Comment 1
<location path="tests/test_stats.py" line_range="364-371" />
<code_context>
-        reduce_sum(arr, "per_channel")
+
+
+@pytest.mark.parametrize("dtype", [np.int32, np.int64, np.float64, np.bool_])
+def test_reduce_sum_accepts_any_dtype(dtype: type) -> None:
+    arr = np.ones((4, 4, 3), dtype=dtype)
+    result = reduce_sum(arr)
+    assert result == arr.size
+    per_ch = reduce_sum(arr, "per_channel")
+    assert per_ch.shape == (3,)
+    assert np.all(per_ch == 16)


</code_context>
<issue_to_address>
**suggestion (testing):** Extend `test_reduce_sum_accepts_any_dtype` to actually exercise the accumulator behavior (overflow/precision) rather than just trivial ones.

This test only checks that `reduce_sum` works for various dtypes and preserves shape/value semantics. It doesn’t verify the new accumulator behavior (`float64` for floats, `int64` for ints/bools, `uint64` for `uint8`). With all-ones inputs, you won’t see overflow or precision issues. Please add a parametrized test (or subtests here) with inputs near `int32`/`int64` limits and a float case sensitive to precision, then assert that the result and/or result dtype matches `np.sum(arr, dtype=<expected_acc>)`. That will lock in the chosen accumulator dtypes and catch regressions.
</issue_to_address>

### Comment 2
<location path="tests/test_stats.py" line_range="353-354" />
<code_context>


 @pytest.mark.parametrize("dtype", [np.int32, np.float64])
-def test_unsupported_dtype_raises(dtype: type) -> None:
+def test_unsupported_dtype_raises_mean_std(dtype: type) -> None:
     arr = np.ones((2, 2, 1), dtype=dtype)
     with pytest.raises(ValueError, match="Unsupported dtype"):
</code_context>
<issue_to_address>
**suggestion (testing):** Broaden `test_unsupported_dtype_raises_mean_std` to cover additional unsupported dtypes (e.g. bool, complex) to better document mean/std constraints.

The new name is clearer, but the test still only covers `np.int32` and `np.float64`. Since `mean`/`std`/`mean_std` should reject all unsupported dtypes, please add at least one non-integer/non-float case (e.g. `np.bool_` and/or `np.complex64`) to assert that these also raise `ValueError`. This will better document the supported dtypes and guard against unintentionally accepting new dtypes without updating tests.

```suggestion
@pytest.mark.parametrize("dtype", [np.int32, np.float64, np.bool_, np.complex64])
def test_unsupported_dtype_raises_mean_std(dtype: type) -> None:
```
</issue_to_address>